home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / C++ A'Link Files / Feb 91 / CPlus.Dev$ 2⁄8⁄91 / 0274-C++ Virt.Fncs no A5 -Feb91 next >
Encoding:
Text File  |  1991-03-06  |  4.5 KB  |  90 lines  |  [TEXT/GEOL]
  1. Item    3758968                         7-Feb-91        13:32PST
  2.  
  3. From:   CDA0461                         DEV Symplex Software,IDV
  4.  
  5. To:     CPLUS.DEV$                      C++ Interest List--Developers
  6.         CPLUS.APPLE$                    C++ Interest List--Apple Employees
  7.  
  8. ------------------------------------------------------------------------------
  9.  
  10. Sub:    C++ Virt.Fncs: no A5 needed
  11.  
  12. [Okay, I admit I'm confused.  I always thought that the CPLUS.DEV$ archives
  13. were simply archives of past discussions in the C++ Discussion folder.  Now I
  14. discover that the two areas are parallel universes, complete with concurrent
  15. discusssions on the feasiblity of virtual functions in standalone code.
  16. Bizarre.  So, my apologies if you have already seen this post.]
  17.  
  18. > We need to solve the problem with virtual functions though...
  19.  
  20. Virtual functions can be used with standalone code:  they do not
  21. require an A5-world.  I have prototyped a post processor that
  22. takes the output from CFront and transforms the code and the virtual
  23. function tables so that it will work within the single code resource
  24. environment of things like XCMDs.  I intend to use
  25. this for my future use in XCMDs and other standalone code.  Warning:
  26. if you thought the Beard A5-world technique was dependent on the
  27. current CFront implementation, you probably would scream at the
  28. the amount of implementation dependent processing I do.  The concept
  29. is certainly not implementation dependent, but I basically have to
  30. change every initialization and use of virtual tables and the
  31. pointers to them.  One advantage of my method is that the virtual tables
  32. are initialized at link time rather than at runtime.
  33.  
  34. There are some problems
  35.  
  36. 1) The post processing of the CFront table has to produce an assembly
  37.    language file as well as the C file.  The asembly language file
  38.    is used to define the virtual function tables as *constant* data
  39.    within the code segment.  MPW C provides no support for this
  40.    (except for string constants).  This is similar to the problem
  41.    that CFront has with Object Pascal linkages:  the dispatch
  42.    tables cannot be output as C code.
  43.  
  44. 2) The main output file is still C.  This means that the access to
  45.    the virtual function has to be expressed as C expressions and
  46.    cannot be optimized to the most efficient machine language form
  47.    There is also the problem that MPW C does not generate optimal
  48.    code for some C expressions required.  A further problem is that
  49.    the MPW Linker only performs its "A5 offset to PC relative"
  50.    transformation magic to the instructions JSR, JMP, LEA and PEA:
  51.    this further limits the operations that can be applied to global
  52.    "data" (that is, the transformed virtual tables) that turn out
  53.    being PC relative.  All of this affects performance, but I don't
  54.    think the "hit" is that high.  (No, I haven't counted cycles nor
  55.    optimized the expressions to the compiler yet.)
  56.  
  57. [ ... and a couple more problems that weren't in the original post ...]
  58.  
  59. 3) The initial prototype was done as a MPW shell editing script so performance
  60. is, um, poor.  I haven't looked at the stream editor that apparently will come
  61. with MPW 3.2:  perhaps that will improve things or perhaps I'll eventually bite
  62. the bullet and translate the post-processor into C. [Or maybe something like
  63. Perl?]
  64.  
  65. 4) The Beard A5-world technique could be extended to support global variables
  66. and static member functions.  My address-to-offset technique does not provide
  67. support for these features:  it addresses only the issue of virtual functions,
  68. but I don't think this limitation is any more severe than the restrictions when
  69. writing standalones in C.
  70.  
  71. So the answer is that virtual functions within standalone code
  72. are feasible and they don't require creation of an A5 world.
  73. Future versions of CFront could incorporate this approach without
  74. requiring drastic changes, but optimal code generation may require
  75. a version of CPlus that generates object code directly.  It is
  76. possible to do this yourself with the current version of MPW C++,
  77. but you have to be willing to accept a post-CFront pre-C
  78. processing step that is sensitive to changes in the CFront
  79. translator.
  80.  
  81. ----------------------------------------------------------------------
  82. John Miller                   (604) 433-1795
  83. Symplex Systems               AppleLink (rarely) CDA0461 (soon to be SYMPLEX)
  84. Burnaby, British Columbia     Fax: (604) 430-8516
  85. Canada                        usenet:  john_miller@mindlink.uucp <== best
  86.  
  87. Macintosh Consulting & Software Development
  88. ----------------------------------------------------------------------
  89.  
  90.